Activities: Abstractions for Collective Behavior

code component. A pattern represents the core of a solution to similar recurring problems, comprising a general arrangement of classes/objects (Gamma et al. 94). Design patterns are more abstract design elements than frameworks (they may be applied in the construction and design of a framework) and their architectural granularity is ner. The activity is a modelling and programming mechanism that may be used to describe a wide variety of programs and program fragments, abstract or concrete. It is an abstraction mechanism, able to be used to create abstractions of varying de nition { from the more abstract/general (design patterns) to the more concrete (frameworks). This abstraction mechanism enables us to have another basic component in the design vocabulary we use when creating such abstractions. Frameworks, design patterns and abstraction mechanisms are also used differently in the program development process. The universe of frameworks and design patterns is not, by nature, nite. Therefore, it will be necessary to search for and identify appropriate frameworks/design patterns that may be applicable to the problem. In the case of a framework, you will need to understand its functionality and how to customize it. With design patterns, it is necessary to recognize the context in which a pattern could be applied and how it should be realized in a concrete design. An abstraction mechanism forms part of the language. It is therefore fundamental in its in uence on how we conceive the world around us, how we initially form our understanding, and then later in expressing it. Such mechanisms give us a basic lexicon with which we can describe higher-level, structured abstractions { like frameworks and design patterns. Card Games and C++. The activity abstraction was investigated in a project described in (May 94). The objective of the project was to explore issues related to the design and construction of object-oriented frameworks { the C++ language was used to build software artifacts through the course of the project. The problem domain on which the study concentrated was that of card games, namely, designing a framework for writing card game applications. Several pieces of software were produced: a Blackjack game (to gain experience in the problem area), a card game framework, and a Five Hundred game. We explored the activity abstraction to address the issue of representing more complicated sequences of interplay yet simplifying their complexity. A framework for activities was created, which later became the basis for a card game framework. This was eventually used to create the Five Hundred game. Limitations were encountered using C++. In its `standard' form, the language lacks multi-sequential and concurrent mechanisms { it is not possible to properly represent multiple executing active objects or reactive activities. Further, there is no support for locality. Overall, the project indicated that most mainstream object-oriented languages had little support for the facilities required to accurately simulate activities. While activities could be implemented in such languages, the absence of such support will result in an implementation solution that does not properly match the design solution { and is less intuitive. Languages should provide more exible constructs (e.g. sub-method inheritance, locality, roles) to enable the design model to be implemented and communicated in a far more natural way. Conference Organizing and the Mediator. The activity abstraction was compared to design patterns, especially the Mediator (Gamma et al. 94), in an implementation project. Descriptions of a subset of a conference organizing system was developed and compared. The intent of the Mediator pattern is to \De ne an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently". Mediator ConcreteMediator ConcreteColleague1 Colleague ConcreteColleague2 Mediator Fig. 23. Structure of the Mediator Pattern In Fig. 23 the structure of the Mediator pattern is reproduced. The Mediator class corresponds to an activity and the Colleague classes to participants. The ConcreteMediator class implements cooperative behaviour by coordinating Colleague objects, and knows and maintains its colleagues. Each Colleague class knows its Mediator object, and each Colleague class communicates with its mediator whenever it would have otherwise communicated with another colleague. From our description in the experiment, the Mediator pattern appears to be similar to how we characterise the collective behavior of activities. Indeed, there is centralisation of control into an object { which manages the interaction between other objects. But while the overall architectural techniques are similar, motivation and focus for collective behavior is di erent. At its heart, the design pattern aims to provide an abstract, general design solution to a set of problems. It is structured to be less well-de ned and more informal. In short, it is an abstraction that is not supposed to be set in concrete: its malleability and generality is its strength. On the other hand, our approach has been at a more elemental and atomic level. The purpose of our research was to inquire into the nature of interaction { rst, our intuitive understanding, then mapping into an object-oriented domain. We have therefore characterised and de ned how we picture activities: the ways in which object-oriented concepts may be applied to them, and how they relate to each other and their participants. The activity is an abstraction mechanism { a type of brick that can be used to build abstractions. In the same way that a class is used to create abstractions (like design patterns), the activity is used as well-de ned component in constructing abstractions. In short, the activity is a mechanism that is supposed to be capable of extension, but well-de ned and less vague. Similar to the class, it is used `as is' rather than requiring a mapping into speci c domains (like design patterns). Therefore, it is possible to envisage building libraries of components that have been constructed using activities (and other mechanisms). The nature of this abstraction mechanism covers the ambit of modelling and programming languages. Thus, we can use activities as building mechanisms in creating modelling abstractions then isomorphically map into a concrete language. Furthermore, the emphasis of the Mediator pattern is to promote loose coupling and encapsulate object interaction. The activity abstraction mechanism also seeks to give force to these goals; of themselves, they are useful and worthwhile objectives. But the emphasis of our inquiry was to represent and give force to the properties of interaction { collective and otherwise. We also investigated beyond the generalised object arrangement scheme embodied by the Mediator. The present paper looks at a dichotomy of how activities can be classi ed into initiating and reactive forms, how they may exploit the power of object-oriented properties in a natural fashion, and supporting the characteristics of activities using concepts such as relations and roles. This clearly exceeds the scope and de nition of the Mediator pattern. In essence, activities are used to build abstractions { solutions. 5 Summary The underlying assumption in this paper is that in existing object-oriented methodologies and languages, objects appear as isolated elements with an implicit and poor description of the interplay structure between them. However, as human beings we identify such interplay structures as another kind of phenomena { usually known as activities { and inspired of this kind of phenomena we introduce an abstraction mechanism, which may be used to model the interplay structures. This language mechanism { the activity { is expressive and powerful for the modeling of organization and interplay of usual objects, { the collective behavior of objects. Related Work. While not discussed explicitly, collective activities are within the ambit of Booch's description of an object (Booch 94): \tangible and/or visible thing; something capable of intellectual apprehension; and something toward which thought or action is directed". Most pointedly, \an object models some part of reality and is therefore something that exists in time and space". In OMT (Rumbaugh et al. 91) the dynamic model is a collection of state diagrams that interact via shared events. A state diagram describes the life cycle of a class of objects { but only from a local perspective. State diagrams are also related to the object structure: the aggregation of objects implies the aggregation of the state diagrams of these objects, resulting in composite states; the specialization of classes implies that a subclass inherits the state diagram of its superclass and together with the state diagram added it works as a composite of concurrent state diagrams. Responsibilities, collaborations, and contracts from (Wirfs-Brock et al. 90) de ne the dependencies between objects and subsystems. However, these are only concerned with the static dependencies, and there is no support for the description of the dynamic interplay between them. Use cases from (Jacobson et al. 92) models system functionality. Use cases { with actors of various kinds { are abstractions of the user's interaction with a system. The actor and system in dialogue is a sequence of transactions each initiated by some stimulus from the actor. An actor may be involved in a number of use cases. A user is seen as an instantiation of an actor, and an actual execution of an interaction session with a user is seen as an instantiation of a use case. This instantiation yields an object. A use case is described by a state transition graph, and user stimuli imply state changes. The description of a use case is organized as a basic course and several alternative courses. A use case may be seen as a special case of a collective activity, which is restricted to the system functionality; it is an abstraction, but no generalization and aggregation hierarchies are discussed for use cases, only the distinction between abstract/concrete use cases, as well as the insertion of a \part" use case into another by means of extends. BETA (Madsen et al. 93) has active objects in the form described here but no mechanisms for supporting the combined execution of the directive of an activity-object and the life cycles of its participants. The aggregation and specialization as presented here can (with a few exceptions) be seen as an adaptation of corresponding mechanisms of BETA. Relations and roles { as described here { are not supported. Contracts (Helm et al. 90) are speci cations of behavioral dependencies between cooperating objects. Contracts are object-external abstractions and include invariants to be maintained by the cooperating objects. The inter-object dependencies are made explicit by means of supporting language mechanisms. The result is that the actions { i.e. the reactions of an object to changes { are removed from the object and described explicitly in the contracts: the objects are turned into reactive objects, whereas the reaction-patterns for an object in its various relations with other objects are described in the corresponding contracts. The intention of the contract mechanism is not the modeling of real world phenomena and their interdependencies { rather, it is to have a mathematical, centralized description that supports provable properties. In (Holland 92) a further development of contracts is presented. Contracts are used for representing and reusing algorithmic programming cliche s. According to (Gamma et al. 94) the Mediator design pattern has the following bene ts and drawbacks: It limits subclassing. It decouples colleagues. Itsimpli es object protocols. It abstracts how objects cooperate. It centralizes con-trol. These qualities are also valid for the activity abstraction. In contrast, thedescription of the Mediator pattern does not include any considerations aboutmulti-sequential execution of participants and activities. A straightforward use ofthe Mediator pattern the multi-sequential case will certainly lead to a lot of un-necessary synchronization. Furthermore, we have presented a notation/languageconstructs for activities for use both in the design phase and in the implementa-tion phase. Most design patterns, including the Mediator pattern, can be usedin both these phases too. The activity is de ned di erently for these phases, inorder to support the informal, intuitive description during design, as well as theformal, though still high level description in terms of relations, roles etc at theimplementation level.There are well-known, existing abstraction mechanisms that are commonlyused to construct control abstractions (Tennent 81). Such examples include theprocedure, coroutine, and various process mechanisms. Similarly, the activitymechanism supports abstraction of control. However, in the same way that theclass is not merely equivalent to a record or structure, the activity mechanismintegrates concepts of functional behavior with object-oriented modelling capa-bilities. Activities can be used to coordinate/control objects { not merely statingan order or sequence of action, but explicitly stating the nature of the interplay:the participants, their relationships, and the actions that take place betweenactivities and participants.In (Aksit et al. 94) Abstract Communication Types (ACTs) are classes/objectsin the object-oriented language Sina. The purpose of ACTs is to structure, ab-stract and reuse object interactions. The composition lters model is applied toabstract communications among objects by introducing input and output com-position lters that a ect the received and sent messages. Using an input ltera message can be accepted or rejected and, for example, initiate the executionof a method. Inheritance is not directly expressed by a language construct butis simulated by the input lter by delegating a message to the methods sup-ported by internal objects. Several primitive lters are available in Sina, e.g.Dispatch, Meta, Error, Wait, and RealTime. In ACTs the Meta lter is used toaccept a received message and to reify this as an object of class Message. Therequirements for ACTs include large scale synchronization and re ection uponmessages; the ACT concept is used as an object-oriented modeling technique inanalysis and design. ACTs appear to be a technical, very comprehensive conceptthat { according to (Aksit et al. 94) { supports a wide variety of object inter-action kinds including action abstraction, distributed algorithms, coordinatedbehavior, inter-object constraints, etc.Results. The main results are summarized as:{ Intuitive and general understanding of the fundamentals of activities as ab-stractions for collective behavior. Activities support the modeling of theorganization of and interplay between objects in object-oriented analysis, design, and implementation.{ Activities support modeling that is more similar and intuitive to our hu-man understanding { in our clustering of information and abstracting ofdetail (particularly of processes): A notation to support the modeling withactivities in analysis and design.{ In the implementation activities o er an orthogonal solution to expressingand manipulating collective behavior of objects:(1) Abstract classes for the support of implementation of activities.(2) Language features for direct support of activities as an abstraction mech-anism in object-oriented programming languages.Challenges. There exist numerous issues with activities that remain to be inves-tigated and/or resolved:Dynamic participation: An activity relates the interplay between various par-ticipating entities. The actual entities participating may change during the ac-tivity { entities may join or leave the activity. This has been achieved to a certaindegree by allowing participants to assume additional roles during the life cycle ofan activity. However, this is a participant-centric view of dynamic participation.From the activity's point of view, it is not possible to tell which participants areinvolved in the activity. (This is a general problem in programming languages {to be able to \know" which objects are associated in a given relationship.)Part-whole activity state access: It is an open question as to the degree of stateaccess enjoyed between part-activities and their whole-activities. Should a part-activity have state access to its enclosing whole-activity? Part-activities will notgenerally execute in isolation or ignorance of their whole-activities' properties {however, a relatively high degree of encapsulation should be enforced betweenactivity classes. Conversely, it is a question as to whether a whole-activity hasautomatic access to the state of its part-activities.ReferencesAksit, M., Wakita, K., Bosch, J., Bergmans, L., Yonezawa, A.: Abstracting Object In-teractions Using Composition Filters. Proceedings of the ECOOP '93 Workshopon Object-based Distributed Processing, Guerraoui, R., Nierstrasz, O., Riveill, M.(Eds.), LNCS 791, Springer-Verlag, 1994.Booch, G.: Object Oriented Analysis and Design with Applications. Ben-jamin/Cummings, 1994.Chin, R. S., Chanson, S. T.: Distributed Object-Based Programming Systems. ACMComputing Surveys, Vol. 23, No. 1, 1991.Dahl, O. J., Myhrhaug, B., Nygaard, K.: SIMULA 67 Common Base Language. Nor-wegian Computing Center, edition February 1984.Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements ofReusable Object-Oriented Software. Addison Wesley, 1994.Harrison, W., Ossher, H.: Subject-Oriented Programming (A Critique of Pure Ob-jects). Proceedings of the Object-Oriented Programming Systems, Languages andApplications Conference, 1993. Helm, R., Holland, I. M., Gangopadhyay, D.: Contracts: Specifying Behavioral Com-positions in Object-oriented Systems. Proceedings of the European Conferenceon Object-Oriented Programming / Object-Oriented Programming Systems, Lan-guages and Applications Conference, 1990.Holland, I. M.: Specifying Reusable Components Using Contracts. Proceedings of theEuropean Conference on Object-Oriented Programming, 1992.Jacobson, I., Christerson, M., Jonsson, P., Overgaard, G.: Object-Oriented SoftwareEngineering, A Use Case Driven Approach. Addison Wesley, 1992.Johnson, R. E., Foote, B.: Designing Reusable Classes. Journal of Object-OrientedProgramming, 1988.Kristensen, B. B.: Transverse Classes & Objects in Object-Oriented Analysis, Design,and Implementation. Journal of Object-Oriented Programming, 1993.Kristensen, B. B.: Transverse Activities: Abstractions in Object-Oriented Program-ming. Proceedings of International Symposium on Object Technologies for Ad-vanced Software (ISOTAS'93), 1993.Kristensen, B. B., May, D. C. M.: Modeling Activities in C++. Proceedings of Inter-national Conference on Technology of Object-Oriented Languages and Systems,1994.Kristensen, B. B., May, D. C. M.: Modeling with Activities: Abstractions for CollectiveBehavior. R 96-2001, IES, Aalborg University, 1996.Kristensen, B. B., K. sterbye: Roles: Conceptual Abstraction Theory & PracticalLanguage Issues. Accepted for publication in a Special Issue of Theory and Practiceof Object Systems (TAPOS) on Subjectivity in Object-Oriented Systems, 1996.Madsen, O. L., M ller-Pedersen, B., Nygaard, K.: Object Oriented Programming inthe Beta Programming Language. Addison Wesley 1993.May, D. C. M.: Frameworks: An Excursion into Metalevel Design and Other Dis-courses. Department of Computer Science, Monash University, 1994.Nassi, I., Shneiderman, B.: Flowchart Techniques for Structured Programming. SigplanNotices, 8 (8), 1973.Rumbaugh, J.: Relations as Semantic Constructs in an Object{Oriented Language.Proceedings of the Object{Oriented Programming Systems, Languages and Appli-cations Conference, 1987.Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W.: Object-OrientedModeling and Design. Prentice-Hall 1991.Stroustrup, B.: The C++ Programming Language. 2/E, Addison-Wesley 1991.Tennent, R. D.: Principles of Programming Languages. Prentice Hall, 1981.Wirfs-Brock, R., Wilkerson, B., Wiener, L.: Designing Object-Oriented Software. Pren-tice Hall, 1990.This article was processed using theLaTEX macro package with LLNCS style